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RECEIVED 

Amendment dated July 6, 2006 CENTRAL PAX CENTER 

Sena] No. 09/842,604 JUL 0 6 2006 

REMARKS 

Itanrtta*. of the rations m in „, offlce Ac|ion js ^ m ^ 

By fc. An^taem, data ,. ,0, 18, and 26 have been amended. Curtly, data* ,-28 „ 

pending in this application. 

Qbiection to claims 10 and 1 a 

The Examiner objected to c Iaims 10 and 18. Applicants have amended independent 
clam* 1, 10, 18, *a 26 to use the term "accessing" instead of locating. This amendment is not 
intended to nan™ the claims but rather to cause the claims to be internally consistent 
Accordmgly, no change in scope is mtended in connection with this amendment. In view of this 
amendment, applicants respectfully request that the objection be withdrawn. 

Rejection of claims ! -6 B-H 1? ^ and M-Mn-^ii sc i02 nv „z ha „^ y 

Claims 1-6, 8-15, 18-23, and 25-28 were rejected under 35 USC 102 as anticipated by 
Shaughnessy, et al. (U.S. Patent No. 6,141,347). This rejection i s respectfully traversed in view 

of the following arguments. 

Multicast trees are commonly established to distribute information to multicast 
parents in an efficient manner. As noted in the background of the invention, there are 
several routing protocols that may be used to establish a multicast tree, two of which are Protocol 
independent Multicast (PIM) and Distance Vector Multicast Routing Protocol (DVMRP) (Sec 
SpeaS.ca.on at page 2, lines 4-6). Once the multicast txee has been established, information 
may be transmitted over the multicast tree. Since not every network device that is connected to 
the multicast tree may wish to participate in every multicast, or may not be authorized to 
parhepate in the multicast, a separate set of protocols have been developed to control 
membership in the multicast. One common protocol that is used to control membership in a 
mumcast is internet Group Management Protoco, (IGMP). Thus, to summary multicast 
routmg protocols such as DVMRP and PIM are used establish the multicast trees or paths 
through the network, and the ability to participate in multicast* taking place over the trees is 
controlled by IGMP or a similar membership control protocol. 

After a multicast tree has been created using a particular routing protocol, it may be 
necessary to go back to read the routing information associated with the tree. For example a 
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network management application may be configured to troubleshoot a multicast tree by reading 
the multicast routing information associated with the tree. 

Generally, from a routing perspective, a particular application will generally use only one 
of the several developed multicast routing protocols to create a multicast tree. Once a multicast 
tree has been established using a multicast routing protocol, the multicast tree may be read by an 
application that is configured to use the same routing protocol that was used to establish the 
multicast tree. (Specification at page 2, lines 8-9). However, applications that are configured to 
read multicast information established using a particular multicast routing protocol have 
conventionally not been able to read information about multicast trees using a routing protocol 
other than that particular multicast routing protocol. For example, a network management 
application configured to troubleshoot DVMRP trees by reading DVMRP multicast routing 
information would not be able to troubleshoot a multicast tree established using PIM. (See e.g. 
specification at page 2, lines 9-11). 

Applicant discovered that multicast information could be stored in a Management 
Information Base (MD3) on routers on the network in a protocol neutral format and then 
retrieved by applications using an available network management protocol, such as Simple 
Network Management Protocol (SNMP). By storing the routing information in a protocol 
neutral format, a network management application may read the routing information regardless 
of what routing protocol was used to establish the multicast tree, 

Shaughnessy teaches that multicast groups (referred to by Shaughnes$y as 44 talk groups") 
may be established and tracked using Internet Group Management Protocol (IGMP). See 
Shaughnessy at Col. 3, lines 56-62. As is well know in the art and as discussed above, IGMP is 
used to enable members to add and leave multicast groups, and enables the routers to keep track 
of which members are associated with which groups. IGMP is thus not a routing protocol, but 
rather is a protocol that allows multicast groups to be managed on the network. 

IGMP works in connection with a multicast routing protocol. The multicast routing 
protocol allows the routers on the network to establish routes to support forwarding of data 
across the network of routers, (see Shaughnessy at Col. 3, lines 62-65). Shaughnessy lists 
several different multicast routing protocols that may be used on the network at Col. 3, line 65 to 
Col. 4, line 8. Several of the multicast routing protocols listed include CBT, PIM-SM, PIM-DM, 
MOSPF, and DVMRP. However, Shaughnessy does not teach or suggest that the routing 
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information from any one of these routing protocols should be stored in any but standard fashion. 
Thus, it would be expected that the routing information would be stored in a protocol specific 
format. Rather, Shaughnessy teaches that a standard multicast routing protocol (such as PIM or 
DVMRP) may be used to establish multicast trees, and that IGMP may be used to control access 
to multicast groups (talk groups) that are established on the multicast trees. 

Shaughnessy's focus is on how to decentralize management of the multicast groups so 
that centralized tracking of group members is not required. (See Shaughnessy at col. 4, lines 14- 
18, col. 2, lines 21-26, and col. 2, lines 56-60). The way in which Shaughnessy achieves 
decentralization is by causing the edge routers or the subscribers to maintain a mapping between 
the talk group IDs and the multicast IP addresses. (See Shaughnessy at col. 4, lines 22-28 and 
col. 4, lines 43-44). By allowing the edge routers or the subscribers to maintain a mapping 
between multicast group ID and the multicast IP address, it is not necessary for this mapping to 
be stored at a central location. 

The mapping between multicast group ID and the multicast IP address is not routing 
information. Talk group identifications are explained by Shaughnessy at Col. 3, lines 15-18: 
"The plurality of subscriber units 210-217 are logically arranged into a talk group[s], which talk 
groups have corresponding talk group identifications..." Thus, talk groups are logical 
associations of subscriber units. To enable the talk group identifications to have meaning to the 
underlying network, these talk group IDs are mapped to particular IP addresses. 

Applicants respectfully submit that Shaughnessy does not anticipate the claims as 
currently drafted. For example, independent claim 1 recites "A method of producing a multicast 
tree for an application configured to use a first multicast routing protocol from existing protocol 
independent multicast routing information in a network, at least some of the protocol 
independent multicast routing information having been created from multicast information 
associated with an application configured to use a second multicast routing protocol. . 

Shaughnessy does not teach producing a multicast tree for an application configured to 
use a first multicast ROUTING protocol from multicast information created by an application 
configured to use a second multicast ROUTING protocol. Rather, Shaughnessy teaches a 
distributed mapping of IGMP information to multicast addresses. Since IGMP is not a 
ROUTING protocol, this does not anticipate the claims as drafted. 
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The Examiner has addressed each aspect of the preamble of claim 1 in the first paragraph 
of the rejection. Specifically, the Examiner has asserted that Shaughnessy teaches: 

• "a method of producing a multicast tree (a spanning tree for a given multicast 
group) for an application configured to use a first multicast routing protocol 
(DVMRP)" 

• "from existing protocol independent multicast routing information (Fig. 2, 
multicast addresses) in a network" 

• "at least some of the protocol independent multicast routing information (Fig. 
2, talk group IDs) having been created from multicast information associated 
with an application configured to user a second multicast routing protocol 
(PIM-DM)." 

Applicants respectfully submit that this last point is incorrect. The talk group IDs are not created 
using PIM-DM but rather are created using IGMP as discussed in greater detail above. 
Accordingly, applicants respectfully request that the rejection of the claims be withdrawn. 

Rejection nf clai ms 7. 16. and 24 under 35 USC 103 

Claims 7, 16, and 24 were rejected under 35 USC 103 over Shaughnessy in view of 
Dobbins (U.S. Patent No. 5,951,649). Claims 7, 16, and 24 are dependent claims and are 
therefore patentable for substantially the same reasons set forth above in connection with the 
independent claims. 

Conclusion 

Applicants respectfully submit that the claims pending in this application arc in condition 
for allowance and respectfully request an action to that effect. If the Examiner believes a 
telephone interview would further prosecution of this application, the Examiner is respectfully 
requested to contact the undersigned at the number indicated below. 
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If any fees are due in connection with this filing, the Commissioner is hereby authorized 
to charge payment of the fees associated with this communication or credit any overpayment to 
Deposit Account No. 502246 (Rcf. NN-13774). 



John C. Gorecki, Esq 
P,0. Box 553 
Carlisle, MA 01741 
Tel: (978) 371-3218 
Fax: (978) 371-3219 
iohn@gorecki.us 
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Respectfully Submitted 



Dated: July 6, 2006 




